Scell beam failure recovery

ABSTRACT

Apparatuses, methods, and systems are disclosed for SCell Beam Failure recovery. One apparatus includes a transceiver that communicates with a SCell in a wireless communication network. The apparatus includes a processor that receives a SR configuration from a wireless communication network, the SR configuration comprising a set of PUCCH resources, where the SR configuration corresponds to one or more logical channels. The processor detects that beam failure procedure has been triggered for the SCell. The processor triggers a scheduling request for SCell beam failure recovery in response to determining that there are no UL-SCH resources available for a new transmission for the transmission of a beam failure MAC CE. The processor transmits SR on the PUCCH resources of the SR configuration in response to triggering the scheduling request for SCell beam failure recovery.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent ApplicationNo. 62/906,576 entitled “Beam Failure Recovery Procedure for SCell” andfiled on Sep. 26, 2019 for Joachim Loehr, Hyejung Jung, Vijay Nangia,Prateek Basu Mallick, and Ravi Kuchibhotla, which application isincorporated herein by reference.

FIELD

The subject matter disclosed herein relates generally to wirelesscommunications and more particularly relates to efficient SCell BeamFailure recovery.

BACKGROUND

The following abbreviations are herewith defined, at least some of whichare referred to within the following description: Third GenerationPartnership Project (“3GPP”), Fifth Generation Core Network (“5GC”),Fifth Generation System (“5GS”), 5G QoS Indicator (“5QI”),Authentication, Authorization and Accounting (“AAA”),Positive-Acknowledgment (“ACK”), Application Function (“AF”), Access andMobility Management Function (“AMF”), Antenna Panel (“AP”), ApplicationProgramming Interface (“API”), Access Stratum (“AS”), Base Station(“BS”), Buffer Status Report (“BSR”), Code Division Multiple Access(“CDMA”), Control Element (“CE”), Core Network (“CN”), Channel QualityIndicator (“CQI”), Channel State Information (“CSI”), CSI ReferenceSignal (“CSI-RS”), Dual Connectivity (“DC”), Downlink ControlInformation (“DCI”), Downlink (“DL”), Demodulation Reference Signal(“DM-RS”), Data Radio Bearer (“DRB”), Discontinuous Transmission(“DTX”), Enhanced Inter-cell Interference Coordination (“eICIC”),Evolved Node-B (“eNB”), Evolved Packet Core (“EPC”), Evolved PacketSystem (“EPS”), Evolved UMTS Terrestrial Radio Access (“E-UTRA”),Evolved UMTS Terrestrial Radio Access Network (“E-UTRAN”), EuropeanTelecommunications Standards Institute (“ETSI”), Guaranteed Bit Rate(“GBR”), New Generation (i.e., 5G) Node-B (“gNB”), Global NavigationSatellite System (“GNSS”), General Packet Radio Service (“GPRS”), GlobalPositioning System (“GPS”), Generic Public Service Identifier (“GPSI”),Global System for Mobile Communications (“GSM”), Hybrid Automatic RepeatRequest (“HARQ”), Home Subscriber Server (“HSS”), Inter-cellInterference Coordination (“ICIC”), Identifier (“ID”), InformationElement (“IE”), Industrial IoT (“HOT”), Internet of Things (“IoT”), KeyPerformance Indicator (“KPI”), Layer-1 (“L1”, also known as the PhysicalLayer), Layer 1 Identifier (“L1 ID”), Layer-2 (“L2”, also known as theLink Layer), Layer 2 Identifier (“L2 ID”), Layer-3 (“L3”, also known asthe Network Layer), Logical Channel (“LCH”), LCH Prioritization (“LCP”),Long Term Evolution (“LTE”), Machine Learning (“ML”), MobilityManagement (“MM”), Mobility Management Entity (“MME”),Negative-Acknowledgment (“NACK”) or (“NAK”), Non-Access Stratum (“NAS”),New Generation Radio Access Network (“NG-RAN”, a RAN used for 5GSnetworks), Neural Network (“NN”), Network Slice Selection AssistanceInformation (“NSSAI”, e.g., a vector value including one or more S-NSSAIvalues), New Radio (“NR”, a 5G radio access technology; also referred toas “5G NR”), Observed Time Difference Of Arrival (“OTDoA”), PC5 5QI(“PQI,” corresponds to QoS for NR V2X communication over the PC5interface), Packet To Data Network (“PDN”), Packet Data Unit (“PDU”,used in connection with ‘PDU Session’), PC5 QoS Flow Indicator (“PFI”),Packet Data Network Gateway (“P-GW”), PC5 Link Identifier (“PLI”),Public Land Mobile Network (“PLMN”), Precoding Matrix Indicator (“PMI”),Physical Random Access Channel (“PRACH”), Physical Sidelink ControlChannel (“PSCCH”), Physical Sidelink Shared Channel (“PSSCH”), QoS FlowIndicator (“QFI”), Quality of Experience (“QoE”), Quality of Service(“QoS”), Random Access Channel (“RACH”), Radio Access Network (“RAN”),Rank Indicator (“RI”), RAN Intelligent Controller (“RIC”), Radio LinkMonitoring (“RLM”), Radio Network Information (“RNI”), RNI Service(“RNIS”), Radio Resource Management (“RRM”), Received Signal ReceivedPower (“RSRP”), Received Signal Strength Indicator (“RSSI”), Receive(“RX”), Sidelink Control Information (“SCI”), Sidelink CSI RS(“S-CSI-RS”), Serving Gateway (“S-GW”), Signal-to-Interference-and-NoiseRatio (“SINR”), Sidelink (“SL”), Sidelink Reference Signal (“SL-RS”),Sidelink Synchronization Signal (“SLSS”), Sidelink SynchronizationSignal Block (“SL-SSB”), Session Management (“SM”), Session ManagementFunction (“SMF”), Single Network Slice Selection Assistance Information(“S-NSSAI”), Service Provider (“SP”), Semi-Persistent Scheduling(“SPS”), Sounding Reference Signal (“SRS”), Sidelink Received SignalReceived Power (“S-RSRP”), Synchronization Signal (“SS”),Synchronization Signal Block (“SSB”), Transport Block (“TB”),Transmission Configuration Indicator (“TCI”), Time Difference of Arrival(“TDoA”), Transmit (“TX”), Uplink Control Information (“UCI”), UnifiedData Management (“UDM”), User Data Repository (“UDR”), UserEntity/Equipment (Mobile Terminal) (“UE”), Uplink (“UL”), Uplink SharedChannel (“UL-SCH”), User Plane (“UP”), Universal MobileTelecommunications System (“UMTS”), UL Time Difference of Arrival(“UTDoA” or “U-TDoA”), UMTS Terrestrial Radio Access (“UTRA”), UMTSTerrestrial Radio Access Network (“UTRAN”), Vehicle-to-everything(“V2X”, V2X communication encompasses both V2V and V2I),Vehicle-to-Infrastructure (“V2I”), Vehicle-to-Vehicle (“V2V”), a UEcapable of vehicular communications using 3GPP protocols (“V2X UE”), andWorldwide Interoperability for Microwave Access (“WiMAX”). As usedherein, “HARQ-ACK” refers to HARQ feedback may represent collectivelythe Positive Acknowledge (“ACK”) and the Negative Acknowledge (“NACK”)and Discontinuous Transmission (“DTX”). ACK means that a TB is correctlyreceived while NACK (or NAK) means a TB is erroneously received. DTXmeans that no TB was detected.

In certain wireless communication systems, Multiple-Input andMultiple-Output (“MIMO”) techniques are used to improve data throughput.In 5G wireless communication systems, massive MIMO may be achieved byusing beams-based cell-sector coverage where several narrow-beamwidthbeams achieve coverage of the cell-sector in place of the singlewide-beam used in previous generations. As the cell coverage isbeams-based, a mobile terminal (UE) in the 5G cell will synchronize to,attach to and report from a beam. Under current 3GPP standards, the UEwill only connect to a single beam. However, each beam in the massiveMIMO system covers a limited area of the cell-sector and so Beam Failure(“BF”) may occur, for example due to UE mobility or environmentalconditions (e.g., radio shadow, interference, etc.).

BRIEF SUMMARY

Disclosed are procedures for SCell Beam Failure recovery. Saidprocedures may be implemented by apparatus, systems, methods, orcomputer program products.

One method of a UE includes receiving a SR configuration from a wirelesscommunication network. Here, the SR configuration comprising a set ofPUCCH resources, where the SR configuration corresponds to one or morelogical channels. The method includes detecting that a beam failurerecovery procedure has been triggered for a SCell in the wirelesscommunication network. The method includes triggering a SR for SCellbeam failure recovery in response to determining that there are noUL-SCH resources available for a new transmission for the transmissionof a beam failure MAC CE. The method includes transmitting SR on thePUCCH resources of the SR configuration in response to triggering the SRfor SCell beam failure recovery.

BRIEF DESCRIPTION OF THE DRAWINGS

A more particular description of the embodiments briefly described abovewill be rendered by reference to specific embodiments that areillustrated in the appended drawings. Understanding that these drawingsdepict only some embodiments and are not therefore to be considered tobe limiting of scope, the embodiments will be described and explainedwith additional specificity and detail through the use of theaccompanying drawings, in which:

FIG. 1 is a schematic block diagram illustrating one embodiment of awireless communication system for SCell Beam Failure recovery;

FIG. 2 is a diagram illustrating one embodiment of beam failure recoveryfor a SCell;

FIG. 3 is a diagram illustrating one embodiment of a protocol stack;

FIG. 4 is a diagram illustrating one embodiment of a user equipmentapparatus that may be used for SCell Beam Failure recovery;

FIG. 5 is a diagram illustrating one embodiment of a network equipmentapparatus that may be used for SCell Beam Failure recovery; and

FIG. 6 is a flowchart diagram illustrating one embodiment of a firstmethod that may be used SCell Beam Failure recovery.

DETAILED DESCRIPTION

As will be appreciated by one skilled in the art, aspects of theembodiments may be embodied as a system, apparatus, method, or programproduct. Accordingly, embodiments may take the form of an entirelyhardware embodiment, an entirely software embodiment (includingfirmware, resident software, micro-code, etc.) or an embodimentcombining software and hardware aspects.

For example, the disclosed embodiments may be implemented as a hardwarecircuit comprising custom very-large-scale integration (“VLSI”) circuitsor gate arrays, off-the-shelf semiconductors such as logic chips,transistors, or other discrete components. The disclosed embodiments mayalso be implemented in programmable hardware devices such as fieldprogrammable gate arrays, programmable array logic, programmable logicdevices, or the like. As another example, the disclosed embodiments mayinclude one or more physical or logical blocks of executable code whichmay, for instance, be organized as an object, procedure, or function.

Furthermore, embodiments may take the form of a program product embodiedin one or more computer readable storage devices storing machinereadable code, computer readable code, and/or program code, referredhereafter as code. The storage devices may be tangible, non-transitory,and/or non-transmission. The storage devices may not embody signals. Ina certain embodiment, the storage devices only employ signals foraccessing code.

Any combination of one or more computer readable medium may be utilized.The computer readable medium may be a computer readable storage medium.The computer readable storage medium may be a storage device storing thecode. The storage device may be, for example, but not limited to, anelectronic, magnetic, optical, electromagnetic, infrared, holographic,micromechanical, or semiconductor system, apparatus, or device, or anysuitable combination of the foregoing.

More specific examples (a non-exhaustive list) of the storage devicewould include the following: an electrical connection having one or morewires, a portable computer diskette, a hard disk, a random-access memory(“RAM”), a read-only memory (“ROM”), an erasable programmable read-onlymemory (“EPROM” or Flash memory), a portable compact disc read-onlymemory (“CD-ROM”), an optical storage device, a magnetic storage device,or any suitable combination of the foregoing. In the context of thisdocument, a computer readable storage medium may be any tangible mediumthat can contain or store a program for use by or in connection with aninstruction execution system, apparatus, or device.

Code for carrying out operations for embodiments may be any number oflines and may be written in any combination of one or more programminglanguages including an object-oriented programming language such asPython, Ruby, Java, Smalltalk, C++, or the like, and conventionalprocedural programming languages, such as the “C” programming language,or the like, and/or machine languages such as assembly languages. Thecode may execute entirely on the user's computer, partly on the user'scomputer, as a stand-alone software package, partly on the user'scomputer and partly on a remote computer or entirely on the remotecomputer or server. In the latter scenario, the remote computer may beconnected to the user's computer through any type of network, includinga local area network (“LAN”) or a wide area network (“WAN”), or theconnection may be made to an external computer (for example, through theInternet using an Internet Service Provider).

Furthermore, the described features, structures, or characteristics ofthe embodiments may be combined in any suitable manner. In the followingdescription, numerous specific details are provided, such as examples ofprogramming, software modules, user selections, network transactions,database queries, database structures, hardware modules, hardwarecircuits, hardware chips, etc., to provide a thorough understanding ofembodiments. One skilled in the relevant art will recognize, however,that embodiments may be practiced without one or more of the specificdetails, or with other methods, components, materials, and so forth. Inother instances, well-known structures, materials, or operations are notshown or described in detail to avoid obscuring aspects of anembodiment.

Reference throughout this specification to “one embodiment,” “anembodiment,” or similar language means that a particular feature,structure, or characteristic described in connection with the embodimentis included in at least one embodiment. Thus, appearances of the phrases“in one embodiment,” “in an embodiment,” and similar language throughoutthis specification may, but do not necessarily, all refer to the sameembodiment, but mean “one or more but not all embodiments” unlessexpressly specified otherwise. The terms “including,” “comprising,”“having,” and variations thereof mean “including but not limited to,”unless expressly specified otherwise. An enumerated listing of itemsdoes not imply that any or all of the items are mutually exclusive,unless expressly specified otherwise. The terms “a,” “an,” and “the”also refer to “one or more” unless expressly specified otherwise.

As used herein, a list with a conjunction of “and/or” includes anysingle item in the list or a combination of items in the list. Forexample, a list of A, B and/or C includes only A, only B, only C, acombination of A and B, a combination of B and C, a combination of A andC or a combination of A, B and C. As used herein, a list using theterminology “one or more of” includes any single item in the list or acombination of items in the list. For example, one or more of A, B and Cincludes only A, only B, only C, a combination of A and B, a combinationof B and C, a combination of A and C or a combination of A, B and C. Asused herein, a list using the terminology “one of” includes one and onlyone of any single item in the list. For example, “one of A, B and C”includes only A, only B or only C and excludes combinations of A, B andC. As used herein, “a member selected from the group consisting of A, B,and C,” includes one and only one of A, B, or C, and excludescombinations of A, B, and C.” As used herein, “a member selected fromthe group consisting of A, B, and C and combinations thereof” includesonly A, only B, only C, a combination of A and B, a combination of B andC, a combination of A and C or a combination of A, B and C.

Aspects of the embodiments are described below with reference toschematic flowchart diagrams and/or schematic block diagrams of methods,apparatuses, systems, and program products according to embodiments. Itwill be understood that each block of the schematic flowchart diagramsand/or schematic block diagrams, and combinations of blocks in theschematic flowchart diagrams and/or schematic block diagrams, can beimplemented by code. This code may be provided to a processor of ageneral-purpose computer, special purpose computer, or otherprogrammable data processing apparatus to produce a machine, such thatthe instructions, which execute via the processor of the computer orother programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart diagramsand/or block diagrams.

The code may also be stored in a storage device that can direct acomputer, other programmable data processing apparatus, or other devicesto function in a particular manner, such that the instructions stored inthe storage device produce an article of manufacture includinginstructions which implement the function/act specified in the flowchartdiagrams and/or block diagrams.

The code may also be loaded onto a computer, other programmable dataprocessing apparatus, or other devices to cause a series of operationalsteps to be performed on the computer, other programmable apparatus orother devices to produce a computer implemented process such that thecode which execute on the computer or other programmable apparatusprovide processes for implementing the functions/acts specified in theflowchart diagrams and/or block diagrams.

The flowchart diagrams and/or block diagrams in the Figures illustratethe architecture, functionality, and operation of possibleimplementations of apparatuses, systems, methods, and program productsaccording to various embodiments. In this regard, each block in theflowchart diagrams and/or block diagrams may represent a module,segment, or portion of code, which includes one or more executableinstructions of the code for implementing the specified logicalfunction(s).

It should also be noted that, in some alternative implementations, thefunctions noted in the block may occur out of the order noted in theFigures. For example, two blocks shown in succession may, in fact, beexecuted substantially concurrently, or the blocks may sometimes beexecuted in the reverse order, depending upon the functionalityinvolved. Other steps and methods may be conceived that are equivalentin function, logic, or effect to one or more blocks, or portionsthereof, of the illustrated Figures.

Although various arrow types and line types may be employed in theflowchart and/or block diagrams, they are understood not to limit thescope of the corresponding embodiments. Indeed, some arrows or otherconnectors may be used to indicate only the logical flow of the depictedembodiment. For instance, an arrow may indicate a waiting or monitoringperiod of unspecified duration between enumerated steps of the depictedembodiment. It will also be noted that each block of the block diagramsand/or flowchart diagrams, and combinations of blocks in the blockdiagrams and/or flowchart diagrams, can be implemented by specialpurpose hardware-based systems that perform the specified functions oracts, or combinations of special purpose hardware and code.

The description of elements in each figure may refer to elements ofproceeding figures. Like numbers refer to like elements in all figures,including alternate embodiments of like elements.

Generally, the present disclosure describes systems, methods, andapparatus for beam failure recovery for a SCell. For BFR on SCell, theUE monitors the quality of an SCell. In case of declaring beam failure,the UE sends the beam failure recovery request (BFRQ) and sends failedSCell index(s) and new beam information (if present) to the network.Informing the network may be achieved using an SR resource on PUCCH forBFR. The BFR SR may be carried on the Primary Cell (“PCell”) or aPrimary Secondary Cell (“PSCell”). Additionally, the UE may send a MACCE providing the network with information about a new beam (if present).Current 3GPP specifications do not restrict MAC CE transmission for BFR,i.e., in Rel-16 the UE can use UL grant of any serving cell fortransmission of SCell BFR MAC CE.

However, the transmission of the SCell BFR MAC CE on a serving cell forwhich Beam Failure was declared might likely fail, e.g., the UE may mostlikely not receive UL grants/DCI on a serving cell with beam failure andhence no UL transmission will take place. However, the UE may beconfigured with UL “configured grant” (e.g., semi-static) resources inaddition to dynamically scheduled uplink transmissions. The disclosureprovides embodiments aiming to avoid transmitting the SCell BFR MAC CEon a serving cell which experienced a beam failure, thereby withoutintroducing multiplexing restriction for the SCell BFR MAC CE.

According to the current agreements a SR-like dedicated PUCCH resourceis introduced in order to request uplink resources for the transmissionof the SCell BFR MAC CE. Furthermore, this SCell BFR PUCCH should have ahigher priority than a normal (data-related) SR for cases when twoSR/PUCCH are colliding. There might be cases where network did notconfigure the UE with SCell BFR PUCCH, in which case the UE may triggerthe random access procedure in order to request UL resources for thetransmission of the SCell BFR MAC CE. Because performing the RACHprocedure—in particular a contention-based RACH procedure—will result indelaying the Beam Failure Recovery procedure (which is according to RAN1agreements time critical), the disclosure provides some solutionsavoiding the extra delay incurred by performing the RACH procedure forcases when UE is not configured SCell BFR PUCCH resources.

According to 3GPP Release 16 (“Rel-16”), the UE considers a SCell BeamFailure Recovery procedure successfully completed upon reception of anUL grant scheduling a new transmission for the HARQ process on whichSCell BFR MAC CE was sent previously, i.e. thereby acknowledging thereception of the S Cell BFR MAC CE. One problem with this definition mayarise for cases when the SCell BFR MAC CE was transmitted on aconfigured grant and—after the expiry of the associatedconfiguredGrantTimer—UE erroneously considers the next CG occasion/ULgrant as the response/acknowledgment for BFR even though the SCell BFRMAC CE was not received by the gNB, i.e. the NDI bit is considered astoggled for configured uplink grants if the correspondingconfiguredGrantTimer is not running. The disclosure provides somesolution for avoiding the situation where UE erroneously the BeamFailure Recovery procedure as successfully completed.

Currently, there is no UE behavior defined for cases when the BeamFailure Recovery procedure was not successfully completed. Thedisclosure provides some well-defined UE behavior for the case that theBFR procedure was not successfully completed.

FIG. 1 depicts a wireless communication system 100 for SCell BeamFailure recovery for wireless devices, according to embodiments of thedisclosure. In one embodiment, the wireless communication system 100includes at least one remote unit 105, a radio access network (“RAN”)120, and a mobile core network 140. The RAN 120 and the mobile corenetwork 140 form a mobile communication network. The RAN 120 may becomposed of a base unit 121 with which the remote unit 105 communicatesusing wireless communication links. Even though a specific number ofremote units 105, base units 121, RANs 120, and mobile core networks 140are depicted in FIG. 1, one of skill in the art will recognize that anynumber of remote units 105, base units 121, RANs 120, and mobile corenetworks 140 may be included in the wireless communication system 100.

In one implementation, the RAN 120 is compliant with the 5G systemspecified in the 3GPP specifications. In another implementation, the RAN120 is compliant with the LTE system specified in the 3GPPspecifications. More generally, however, the wireless communicationsystem 100 may implement some other open or proprietary communicationnetwork, for example WiMAX, among other networks. The present disclosureis not intended to be limited to the implementation of any particularwireless communication system architecture or protocol.

In one embodiment, the remote units 105 may include computing devices,such as desktop computers, laptop computers, personal digital assistants(“PDAs”), tablet computers, smart phones, smart televisions (e.g.,televisions connected to the Internet), smart appliances (e.g.,appliances connected to the Internet), set-top boxes, game consoles,security systems (including security cameras), vehicle on-boardcomputers, network devices (e.g., routers, switches, modems), or thelike. In some embodiments, the remote units 105 include wearabledevices, such as smart watches, fitness bands, optical head-mounteddisplays, or the like. Moreover, the remote units 105 may be referred toas the UEs, subscriber units, mobiles, mobile stations, users,terminals, mobile terminals, fixed terminals, subscriber stations, userterminals, wireless transmit/receive unit (“WTRU”), a device, or byother terminology used in the art.

The remote units 105 may communicate directly with one or more of thebase units 121 in the RAN 120 via uplink (“UL”) and downlink (“DL”)communication signals. Furthermore, the UL and DL communication signalsmay be carried over the wireless communication links. Here, the RAN 120is an intermediate network that provides the remote units 105 withaccess to the mobile core network 140.

In some embodiments, the remote units 105 communicate with anapplication server 151 via a network connection with the mobile corenetwork 140. For example, an application 107 (e.g., web browser, mediaclient, telephone/VoIP application) in a remote unit 105 may trigger theremote unit 105 to establish a PDU session (or other data connection)with the mobile core network 140 via the RAN 120. The mobile corenetwork 140 then relays traffic between the remote unit 105 and theapplication server 151 in the packet data network 150 using the PDUsession. The PDU session represents a logical connection between theremote unit 105 and the UPF 141. In order to establish the PDU session,the remote unit 105 must be registered with the mobile core network.Note that the remote unit 105 may establish one or more PDU sessions (orother data connections) with the mobile core network 140. As such, theremote unit 105 may concurrently have at least one PDU session forcommunicating with the packet data network 150 and at least one PDUsession for communicating with another data network (not shown).

The base units 121 may be distributed over a geographic region. Incertain embodiments, a base unit 121 may also be referred to as anaccess terminal, an access point, a base, a base station, a Node-B, aneNB, a gNB, a Home Node-B, a relay node, a RAN node, or by any otherterminology used in the art. The base units 121 are generally part of aradio access network (“RAN”), such as the RAN 120, that may include oneor more controllers communicably coupled to one or more correspondingbase units 121. These and other elements of radio access network are notillustrated but are well known generally by those having ordinary skillin the art. The base units 121 connect to the mobile core network 140via the RAN 120.

The base units 121 may serve a number of remote units 105 within aserving area, for example, a cell or a cell sector, via a wirelesscommunication link. As depicted, a base unit 121 may support a specialcell 123 (i.e., a PCell or PScell) and/or a SCell 125. The base units121 may communicate directly with one or more of the remote units 105via communication signals. Generally, the base units 121 transmit DLcommunication signals to serve the remote units 105 in the time,frequency, and/or spatial domain. Furthermore, the DL communicationsignals may be carried over the wireless communication links. Thewireless communication links may be any suitable carrier in licensed orunlicensed radio spectrum. The wireless communication links facilitatecommunication between one or more of the remote units 105 and/or one ormore of the base units 121.

In one embodiment, the mobile core network 140 is a 5G core (“5GC”) orthe evolved packet core (“EPC”), which may be coupled to a packet datanetwork 150, like the Internet and private data networks, among otherdata networks. A remote unit 105 may have a subscription or otheraccount with the mobile core network 140. Each mobile core network 140belongs to a single public land mobile network (“PLMN”). The presentdisclosure is not intended to be limited to the implementation of anyparticular wireless communication system architecture or protocol.

The mobile core network 140 includes several network functions (“NFs”).As depicted, the mobile core network 140 includes one or more user planefunctions (“UPFs”) 141. The mobile core network 140 also includesmultiple control plane functions including, but not limited to, anAccess and Mobility Management Function (“AMF”) 143 that serves the RAN120, a Session Management Function (“SMF”) 145, a Policy ControlFunction (“PCF”) 147, and a Unified Data Management function (“UDM”)149. In various embodiments, the mobile core network 140 may alsoinclude an Authentication Server Function (“AUSF”), a Network RepositoryFunction (“NRF”) (used by the various NFs to discover and communicatewith each other over APIs), a Network Exposure Function (“NEF”), orother NFs defined for the 5GC.

In various embodiments, the mobile core network 140 supports differenttypes of mobile data connections and different types of network slices,wherein each mobile data connection utilizes a specific network slice.Here, a “network slice” refers to a portion of the mobile core network140 optimized for a certain traffic type or communication service. Eachnetwork slice includes a set of CP and/or UP network functions. Anetwork instance may be identified by a S-NSSAI, while a set of networkslices for which the remote unit 105 is authorized to use is identifiedby NSSAI. In certain embodiments, the various network slices may includeseparate instances of network functions, such as the SMF 145 and UPF141. In some embodiments, the different network slices may share somecommon network functions, such as the AMF 143. The different networkslices are not shown in FIG. 1 for ease of illustration, but theirsupport is assumed.

Although specific numbers and types of network functions are depicted inFIG. 1, one of skill in the art will recognize that any number and typeof network functions may be included in the mobile core network 140.Moreover, where the mobile core network 140 is an EPC, the depictednetwork functions may be replaced with appropriate EPC entities, such asan MME, S-GW, P-GW, HSS, and the like. In certain embodiments, themobile core network 140 may include a AAA server.

In various embodiments, a remote unit 105 may experience Beam Failurewhile in the coverage area of the base unit 121, wherein the remote unit105 triggers a Beam Failure Recovery procedure 130. In certainembodiments, the remote unit 105 responds to Beam Failure by selectivelyignoring received UL grants allocating resources, as discussed infurther detail below. In certain embodiments, the remote unit 105transmits a SCell Beam Failure Recovery (“BFR”) MAC control element(“CE”) for a SCell with Beam Failure according to an available dynamicUL grant without performing BFR scheduling request (“SR”), as discussedin further detail below. In certain embodiments, the remote unit 105 mayuse any valid SR Physical Uplink Control Channel (“PUCCH”) resourcesconfigured for the remote unit 105 in case there is no valid PUCCHresource configured for the SCell BFR SR and the remote unit 105 has noavailable UL resources for the transmission of the BFR MAC CE, asdiscussed in further detail below.

In certain embodiments, the remote unit 105 is configured by the networkwhich of the SR configurations being configured for data-related BufferStatus Report (“BSR”) and/or SR triggering (referred to as “BSR/SRtriggering”), e.g. SR configurations corresponding to a logicalchannel(s), to use for sending a SCell BFR SR, as discussed in furtherdetail below. In certain embodiments, the remote unit 105 considers aSCell Beam Failure Recovery (“BLR”) procedure successfully completedupon reception of a dynamic UL grant scheduling a new transmission forthe HARQ process on which SCell BFR MAC CE was sent previously, asdiscussed in further detail below.

In certain embodiments, the remote unit 105 (re)triggers SCell BFR SR(if there is no available UL grant) or instructs the Multiplexing andAssembly procedure to generate the SCell BFR MAC CE (if there is anavailable UL grant) upon expiry of a SCell BFR timer, as discussed infurther detail below. In certain embodiments, the remote unit 105 uses aconventional (logical channel related) SR configuration/PUCCH resourcesconfigured for the remote unit 105 on the Special Cell (“SpCell”) totransmit the BFR SR (if SR is configured on the SpCell) or performs arandom access (“RACH”) procedure on the SpCell (if SR is not configuredon the SpCell), as discussed in further detail below.

While FIG. 1 depicts components of a 5G RAN and a 5G core network, thedescribed embodiments for beam failure recovery for a SCell apply toother types of communication networks and RATs, including IEEE 802.11variants, GSM, GPRS, UMTS, LTE variants, CDMA 2000, Bluetooth, ZigBee,Sigfoxx, and the like. For example, in an LTE variant involving an EPC,the AMF 143 may be mapped to an MME, the SMF 145 may be mapped to acontrol plane portion of a PGW and/or to an MME, the UPF 141 may bemapped to an SGW and a user plane portion of the PGW, the UDM/UDR 149maps to an HSS, etc.

In the following descriptions, the term “RAN Node” is used for the basestation but it is replaceable by any other radio access node, e.g., gNB,eNB, BS, AP, NR, etc. Further the operations are described mainly in thecontext of 5G NR. However, the proposed solutions/methods are alsoequally applicable to other mobile communication systems supportingbeamforming and/or beams-based cell-sectors.

FIG. 2 depicts a recovery procedure 200 between a UE 205 and a RAN node211 in a wireless communication network 210. Note that the UE 205 may beone embodiment of the remote unit 105, described above. Likewise, thewireless communication network 210 may be an embodiment of the RAN 120and mobile core network 140, described above. While the specific cellsare not shown in FIG. 2, it is assumed that the UE 205 communicates withthe wireless communication network 210 using a primary cell (e.g., atleast one cell from a primary cell group or master cell group) and atleast one secondary cell (e.g., one or more secondary cells from theprimary/master cell group and/or from a secondary cell group).

During the procedure 200, the UE 205 experiences Beam Failure for aSecondary Cell (“SCell”) 125 provided by the RAN node 211. Initially,the UE 205 detects Beam Failure for the SCell (see block 215) andtriggers a SCell Beam Failure Recovery procedure (see block 220).Various solutions for SCell Beam Failure Recovery (“BFR”) are describedbelow. In the depicted embodiment, the UE 205 sends a beam failurerecover request to the RAN node 211 (see messaging 225). In oneembodiment, the beam failure recover request may trigger thetransmission of a SR sent according to a SR configuration. In anotherembodiment, the beam failure recover request may be a MAC CE sent usinga UL-SCH resource. In certain embodiments, the UE 205 optionallymonitors for a BFR response from the RAN node 211 (see block/messaging230).

FIG. 3 depicts a protocol stack 300, according to embodiments of thedisclosure. While FIG. 3 shows the UE 205, the RAN node 211 and themobile core network 140, these are representative of a set of remoteunits 105 interacting with a base unit 121 and a mobile core network140. As depicted, the protocol stack 300 comprises a User Plane protocolstack 305 and a Control Plane protocol stack 310. The User Planeprotocol stack 305 includes a physical (“PHY”) layer 315, a MediumAccess Control (“MAC”) sublayer 320, a Radio Link Control (“RLC”)sublayer 325, a Packet Data Convergence Protocol (“PDCP”) sublayer 330,and Service Data Adaptation Protocol (“SDAP”) layer 335. The ControlPlane protocol stack 310 also includes a physical layer 315, a MACsublayer 320, a RLC sublayer 325, and a PDCP sublayer 330. The ControlPlace protocol stack 310 also includes a Radio Resource Control (“RRC”)layer and a Non-Access Stratum (“NAS”) layer 345.

The AS protocol stack for the Control Plane protocol stack 310 consistsof at least RRC, PDCP, RLC and MAC sublayers, and the physical layer.The AS protocol stack for the User Plane protocol stack 305 consists ofat least SDAP, PDCP, RLC and MAC sublayers, and the physical layer. TheLayer-2 (“L2”) is split into the SDAP, PDCP, RLC and MAC sublayers. TheLayer-3 (“L3”) includes the RRC sublayer 340 and the NAS layer 345 forthe control plane and includes, e.g., an Internet Protocol (“IP”) layeror PDU Layer (note depicted) for the user plane. L1 and L2 are referredto as “lower layers”, while L3 and above (e.g., transport layer,application layer) are referred to as “higher layers” or “upper layers”.

The physical layer 315 offers transport channels to the MAC sublayer320. The MAC sublayer 320 offers logical channels to the RLC sublayer325. The RLC sublayer 325 offers RLC channels to the PDCP sublayer 330.The PDCP sublayer 330 offers radio bearers to the SDAP sublayer 335and/or RRC layer 340. The SDAP sublayer 335 offers QoS flows to themobile core network 140 (e.g., 5GC). The RRC layer 340 provides for theaddition, modification, and release of Carrier Aggregation and/or DualConnectivity. The RRC layer 340 also manages the establishment,configuration, maintenance, and release of Signaling Radio Bearers(“SRBs”) and Data Radio Bearers (“DRBs”). In certain embodiments, a RRCentity functions for detection of and recovery from radio link failure.

According to a first solution, the UE 205 ignores received uplink grantsallocating uplink resources on a SCell 125 for which: 1) Beam Failurewas detected/declared or 2) a Beam Failure Recovery procedure wasinitiated and not successfully completed. According to oneimplementation of the first solution, the UE 205 autonomously (i.e.,acting without explicit signaling or instruction from the RAN node 211)deactivates or clears any configured uplink grants. Additionally, the UE205 may also clear any PUSCH resources for semi-persistent CSI reportingfor a SCell 125 when: 1) Beam Failure was detected or 2) Beam FailureRecovery procedure was initiated for that SCell 125. In someembodiments, the UE 205 may also stop transmission on PUCCH if the SCell125 is configured with PUCCH. Similarly, the UE 205 may also stop SRStransmission except possibly for SRS in a resource set with usage set to‘beamManagement’.

In one implementation of the first solution, the UE 205 (specifically aMAC entity at the MAC layer 320 of the UE 205), stops uplinktransmissions for a SCell 125 upon initiating Beam Failure Recoveryprocedure for that SCell 125 and considers the timeAlignmentTimer (TAT)associated with the SCell 125 as expired. By stopping UL transmissionson a SCell 125 for which the Beam Failure Recovery procedure wasinitiated and thereby ensuring not to transmit the SCell BFR MAC CE on aSCell 125 experiencing a Beam Failure, a transmission failure of theSCell BFR MAC CE and consequently delayed Beam Failure Recoveryprocedure is avoided.

In one embodiment of the first solution, stopping UL transmissions on aSCell 125 for which the Beam Failure Recovery procedure was initiatedmay be achieved by considering the timeAlignmentTimer associated withthat SCell 125 as expired. For example, 3GPP TS 38.321, section 5.2 maybe modified to specify that “When the MAC entity stops uplinktransmission for a SCell due to the fact that a Beam Failure Recoveryprocedure was initiated for that SCell, the MAC entity considers thetimeAlignmentTimer associated with the SCell as expired.” “When the MACentity stops uplink transmissions for an SCell due to the fact that themaximum uplink transmission timing difference between Timing AdvanceGroups (“TAGs”) of the MAC entity or the maximum uplink transmissiontiming difference between TAGs of any MAC entity of the UE is exceeded,the MAC entity considers the timeAlignmentTimer associated with theSCell as expired. Note that a TAG refers to includes one or more servingcells with the same UL timing advance and the same DL timing referencecell. If a TAG contains the PCell, it is referred to as Primary TimingAdvance Group (“pTAG”). If a TAG contains only SCell(s), it is referredto as Secondary Timing Advance Group (“sTAG”).

Additionally, when the MAC entity stops uplink transmission for a SCell125 due to the fact that a Beam Failure Recovery procedure was initiatedfor that SCell 125, the MAC entity considers the timeAlignmentTimerassociated with the SCell as expired. Note that the MAC entity is not toperform any uplink transmission on a Serving Cell except the RandomAccess Preamble transmission when the timeAlignmentTimer associated withthe TAG to which this Serving Cell belongs is not running. Furthermore,when the timeAlignmentTimer associated with the Primary Timing AdvanceGroup is not running, the MAC entity is not to perform any uplinktransmission on any Serving Cell except the Random Access Preambletransmission on the SpCell.

According to a second solution, the UE 205 may transmit a SCell BFR MACCE for a SCell with Beam Failure according to an available dynamic ULgrant without performing BFR SR if the available dynamic UL grant is ona SpCell. However, if there is no available UL grant on the SpCell, thenthe UE 205 may perform BFR SR (e.g., if BFR SR PUCCH is configured) orperform a RACH procedure on the SpCell (e.g., if BFR SR PUCCH is notconfigured). The UE 205 then waits for an UL grant on the SpCell.

In certain embodiments, the SCell BFR MAC CE may be prioritized overuser-plane data to expedite beam recovery in the SCell 125. For example,if the UE 205 is in a transmit-power limited state and accordingly hasto apply power scaling to a lower priority uplink transmission, then aPUSCH transmission on a SpCell 123 is prioritized over a PUSCHtransmission on a SCell 125 within a given cell group (e.g. MCG or SCG).Thus, dropping of a PUSCH transmission including the SCell BFR MAC CEcan be minimized by including the BFR MAC CE only in a PUSCH of theSpCell 123 and restricting not to multiplex the SCell BFR MAC CE in aPUSCH of the SCell (where the SCell 125 is any SCell in the cell group).

As used herein, a master node refers to the RAN node 211 that providesthe control plane connection to the core network 140, e.g., in case ofdual connectivity (“DC”). A RAN node 211 with no control planeconnection to the core network 140, but providing additional resourcesto the UE 205 (e.g., in the case of DC) is referred to as a “secondarynode”. Note that serving cells may be grouped together into one or morecell groups. A group of serving cells associated with the master node isreferred to as a “master cell group” or “MCG”. The MCG contains thePCell and optionally one or more SCells. A secondary cell group (“SCG”)refers to a group of serving cells associated with the secondary node,comprising of the SpCell 123 (e.g., PSCell) and optionally one or moreSCells.

Under MCG, there may be many Cells, one of which is used to initiateinitial access. This cell is called PCell. Note that a PCell and anSCell in the MCG may be used together by Carrier Aggregation (“CA”)technology. The PSCell the “main” cell of the SCG and is the cell forinitial access under the SCG. Note that the PSCell and an SCell in theSCG may be used together under CA. The SpCell 123 refers to the PCelland/or the PSCell.

In one implementation of the second solution, if the UE 205 ispower-limited (i.e., if a total UE transmit power for a PUSCH or PUCCHor PRACH or SRS transmission in a respective transmission occasion iwould exceed the configured maximum power, Pcmax(i)), then—from a powerallocation perspective—a PUSCH with BFR MAC-CE has the highest priorityexcept for PRACH transmission on PCell. As such, the priority order (indescending order) can be: PRACH transmission on PCell>PUSCH with BFRMAC-CE>PUCCH with at HARQ-ACK/SR or PUSCH with HARQ-ACK>PUCCH/PUSCH withCSI>PUSCH without HARQ-ACK/CSI>aperiodic SRS>periodic/semi-persistentSRS or PRACH on SCell.

In another example, PUCCH/PUSCH with HARQ-ACK may have higher prioritythan PUSCH with BFR MAC-CE. Here, the priority order (in descendingorder) may be: PRACH transmission on PCell>PUCCH/PUSCH withHARQ-ACK>PUSCH with BFR MAC-CE>PUCCH transmission with SRonly>PUCCH/PUSCH with CSI>PUSCH without HARQ-ACK/CSI>aperiodicSRS>periodic/semi-persistent SRS or PRACH on SCell. According to yetanother alternative UE may—when being power-limited—prioritize PUSCHwith BFR MAC CE over a PRACH transmission on PCell, i.e. PUSCH with BFRMAC having the highest priority in the priority order.

According to a third solution, the UE 205 may use any valid SR PUCCHresources configured for the UE 205 in case there is no valid PUCCHresource configured for the SCell BFR SR and the UE 205 has no availableUL resources for the transmission of the BFR MAC CE. In oneimplementation of the third solution, the UE 205 may use any valid SRPUCCH resources configured for the UE 205 in case the UE 205 has no BFRSR configuration. In various embodiments, a BFR SR configurationincludes a set of PUCCH resources for SCell Beam Failure RecoveryRequest (“BFRQ”).

In one implementation of the third solution, the UE 205 uses the SRconfiguration providing the earliest available PUCCH resources for caseswhen the UE 205 has no valid PUCCH resources for BFR SR. Alternatively,the UE 205 may use some PUCCH resources of some preconfigured SRconfiguration, e.g., SR configuration associated with a URLLC LCH, forcases when the UE 205 is not configured with a BFR SR configuration.Beneficially, using one of the configured “conventional” (data-related)SR configurations, i.e., SR configuration associated with some LCH,rather than using a random access procedure for requesting UL resourceswill speed up the Beam Failure Recovery Request procedure for cases whenthe UE 205 has no BFR SR configuration and no available UL grant to sendthe BFR MAC CE.

It should be noted that the transmission of BFR SR/MAC CE is timecritical. According to one implementation of the third solution, the UE205 behavior for cases when SCell BFR SR has been triggered and the UE205 has no available UL-SCH resources is as follows: If there are validPUCCH resources configured for the BFR SR, then the UE 205 uses thosePUCCH resources for requesting PUSCH resources. However, if there are novalid PUCCH resources configured for BFR SR, then the UE 205 may use anyother valid PUCCH resource configured for SR for requesting PUSCHresources. For cases when the UE 205 does not have any valid PUCCHresources, then the UE 205 initiates the RACH procedure to request PUSCHresources.

In one implementation of the third solution, when the UE 205 has a validPUCCH resource (BFR SR PUCCH resource, or any other valid PUCCH resourceconfigured for SR) and available UL-SCH resources that start after thestart of the valid PUCCH resource), the UE 205 selects whether totransmit PUCCH or PUSCH corresponding to the available UL-SCH dependingon the time gap between the start of the valid PUCCH resource and startof the PUSCH. In one example, if the time gap is greater than athreshold then the UE 205 transmit the PUCCH, otherwise the UE 205transmit PUSCH with BFR MAC CE. In one example, the time gap thresholdmay be based on the UL HARQ RTT timer or configured by higher layers.The available UL-SCH resource may correspond to a valid PUSCH associatedwith a UL grant that is received at least a certain time interval orcut-off time before the start of the valid PUCCH resource. The cut-offtime may be related to the CSI processing time or configured by higherlayers.

According to a fourth solution, the UE 205 is configured by the networkwhich of the SR configurations being configured for data-related BSR/SRtriggering, e.g., SR configurations corresponding to a logicalchannel(s), to use for sending a SCell BFR SR. According to oneimplementation of the fourth solution, the BFR SR may be mapped to a SRconfiguration to which a logical channel may be also mapped to, i.e.,the SR configuration corresponds to one or more LCHs and a SCell BFR SR.Beneficially, the need for having a separate SR configuration just forthe purpose of SCell BFR SR is avoided, by allowing to map a logicalchannel as well as SCell BFR SR to a SR configuration. Accordingly, theSCell BFR SR may be treated like a virtual LCH from a configurationperspective. Note here that the fourth solution may be treated as anextension to the third solution.

According to a fifth solution, the UE 205 considers a SCell Beam FailureRecovery procedure successfully completed upon reception of a dynamic ULgrant scheduling a new transmission for the HARQ process on which SCellBFR MAC CE was sent previously. In one implementation of the fifthsolution, the UE 205 is restricted to send the SCell BFR MAC CE only onUL-SCH resources allocated by a dynamic UL grant, i.e. the UE 205 is notallowed to send a SCell BFR MAC CE on a configured grant resource. Byintroducing such restriction, a situation is avoided where the UE 205has an UL grant for a HARQ process on which the SCell BFR MAC CE wassent indicating a new transmission (after configuredGrantTimer expiry)even though the UL transmission containing the SCell BFR MAC CE was notreceived by the RAN node 211. Therefore, criteria for successfulcompletion of a SCell Beam Failure Recovery procedure is the receptionof a dynamic UL grant, e.g., PDCCH/DCI addressed to the C-RNTI,indicating a new transmission, i.e. toggled NDI.

According to a sixth solution, the UE 205 (re)triggers SCell BFR SR (ifthere is no available UL grant) or instructs the Multiplexing andAssembly procedure to generate the SCell BFR MAC CE (if there is anavailable UL grant) upon expiry of a SCell BFR timer. Such newtimer—referred to as “SCell BFR timer”—defines the time period duringwhich the UE 205 monitors for the reception of the BFR response message,e.g., UL grant indicating a new transmission for the HARQ process onwhich the SCell BFR MAC CE was transmitted. In various embodiments, theUE 205 starts the SCell BFR timer and may restart the SCell BFR timer ateach HARQ retransmission in the first symbol after the end of the SCellBFR MAC CE transmission or in the first symbol after the end of theSCell BFR SR transmission. While the SCell BFR timer is running, the UE205 is in DRX Active Time, according to one implementation of the sixthsolution.

According to a seventh solution, a BFR SR configuration including aPUCCH resource for SCell Beam Failure Recover Request (“BFRQ”) andparameters related to a SCell BFR SR procedure can be configured on aSpCell 123 or a PUCCH SCell (i.e. an SCell configured with the RRCparameter ‘PUCCH-Config’). In one implementation, the parameters relatedto the SCell BFR SR procedure include ‘bfr-sr-ProhibitTimer’ and‘bfr-sr-TransMax’, where the UE 205 starts the bfr-sr-ProhibitTimerwithin a MAC entity of the UE 205 instructing a physical layer of the UE205 to signal the BFR SR on one valid PUCCH resource for BFR SR andbfr-sr-TransMax is the maximum number of BFR SR transmissions for agiven BFR SR procedure. Note here that the seventh solution may betreated as an extension to the sixth solution.

According to an eighth solution, if a the UE 205 receives a BFR SRconfiguration configuring PUCCH resources not on a SpCell 123, but on aPUCCH SCell (e.g. for PUCCH load balancing across cells) and the numberof BFR SR transmissions on the PUCCH SCell reaches to the maximumallowed BFR SR transmissions (i.e. the value of bfr-sr-TransMax), thenthe UE 205 uses a conventional (logical channel related) SRconfiguration/PUCCH resources configured for the UE 205 on the SpCell123 to transmit the BFR SR (i.e., if SR is configured on the SpCell 123)or performs a random access procedure on the SpCell 123 (i.e., if SR isnot configured on the SpCell 123). In one implementation of the eighthsolution, the random access procedure on the SpCell 123 is acontention-based random access. In another implementation of the eighthsolution, the UE 205 is configured with a dedicated PRACH preamble forthe BFR SR.

According to a ninth solution, for cases when the UE 205 transmits aconventional (LCH-related) SR on the SpCell 123 and a SCell BFR SR onthe PUCCH SCell in overlapped time duration, the UE 205 prioritizes aPUCCH including the conventional SR on the SpCell 123 over a PUCCHincluding the BFR SR on the PUCCH SCell, e.g. for power scaling.

FIG. 4 depicts a user equipment apparatus 400 that may be used for SCellBeam Failure recovery, according to embodiments of the disclosure. Invarious embodiments, the user equipment apparatus 400 is used toimplement one or more of the solutions described above. The userequipment apparatus 400 may be one embodiment of the remote unit 105and/or the UE 205, described above. Furthermore, the user equipmentapparatus 400 may include a processor 405, a memory 410, an input device415, an output device 420, and a transceiver 425.

In some embodiments, the input device 415 and the output device 420 arecombined into a single device, such as a touchscreen. In certainembodiments, the user equipment apparatus 400 may not include any inputdevice 415 and/or output device 420. In various embodiments, the userequipment apparatus 400 may include one or more of: the processor 405,the memory 410, and the transceiver 425, and may not include the inputdevice 415 and/or the output device 420.

As depicted, the transceiver 425 includes at least one transmitter 430and at least one receiver 435. Here, the transceiver 425 communicateswith one or more cells supported by one or more base units 121,including a PCell and at least one SCell. Additionally, the transceiver425 may support at least one network interface 440 and/or applicationinterface 445. The application interface(s) 445 may support one or moreAPIs. The network interface(s) 440 may support 3GPP reference points,such as Uu and PC5. Other network interfaces 440 may be supported, asunderstood by one of ordinary skill in the art.

The processor 405, in one embodiment, may include any known controllercapable of executing computer-readable instructions and/or capable ofperforming logical operations. For example, the processor 405 may be amicrocontroller, a microprocessor, a central processing unit (“CPU”), agraphics processing unit (“GPU”), an auxiliary processing unit, a fieldprogrammable gate array (“FPGA”), or similar programmable controller. Insome embodiments, the processor 405 executes instructions stored in thememory 410 to perform the methods and routines described herein. Theprocessor 405 is communicatively coupled to the memory 410, the inputdevice 415, the output device 420, and the transceiver 425.

In various embodiments, the processor 405 controls the user equipmentapparatus 400 to implement the above described UE behaviors. Forexample, via the transceiver 425, the processor 405 receives a SRconfiguration from a network entity in a wireless communication network(i.e., from a gNB in a RAN). Here, the SR configuration comprises a setof PUCCH resources, where the SR configuration corresponds to one ormore logical channels. In some embodiments, the processor 405 receives aconfiguration from the network entity indicating that SCell BFR ismapped to the SR configuration.

In some embodiments, receiving the SR configuration includes receiving aBFR SR configuration including a PUCCH resource for a SCell BFRQ andincluding parameters related to a SCell BFR SR procedure. In oneembodiment, the BFR SR configuration is configured on one of: a primarycell and a primary secondary cell (i.e., on a SpCell 123). In anotherembodiment, the BFR SR configuration is configured on a different SCell(i.e., an SCell configured with the RRC parameter ‘PUCCH-Config’).

The processor 405 detects that beam failure procedure has been triggeredfor the SCell. The processor 405 triggers a SR for SCell BFR in responseto determining that there are no UL-SCH resources available for anewtransmission for the transmission of a beam failure MAC CE. Theprocessor 405 transmits SR on the PUCCH resources of the SRconfiguration in response to triggering the SR for SCell BFR. In someembodiments, transmitting SR on the PUCCH resources of the SRconfiguration includes sending a BFR SR using any valid SR PUCCHresources configured for the UE in response to determining that there isno valid PUCCH resource configured for SCell BFR SR. In someembodiments, the processor 405 ignores received UL grants allocatingresources on the SCell 125 until successful completion of a BFRprocedure 130.

In some embodiments, the processor 405 further determines that an ULresource allocation is available for a new transmission in response toafter having transmitted the SR. Here, the UL resource allocation isassociated with a HARQ process and controls the transceiver to transmita beam failure MAC CE on the allocated uplink resource. Note that the ULresource allocation for a new transmission is allocated later in timethan the SR transmission. For example, the network entity (i.e., gNB)allocates UL resource in response to receiving SR from UE.

In some embodiments, the processor 405 receives (i.e., via thetransceiver 425) a dynamic UL grant that schedules a new transmissionfor the HARQ process on which the beam failure MAC CE was transmitted.The processor 405 determines that a BFR procedure 130 is successfullycompleted in response to reception of the dynamic UL grant. In suchembodiments, the dynamic UL grant includes DCI addressed to a C-RNTI ofthe UE, where the dynamic UL grant has an NDI that is toggled ascompared to a reference NDI for the HARQ process.

In some embodiments, the processor 405 transmits the beam failure MAC CEfor the SCell 125 according to an available dynamic uplink grant inresponse to determining that there are UL-SCH resources available for anew transmission. In certain embodiments, the processor 405 prevents thebeam failure MAC CE from being sent on a semi-persistently scheduleduplink resource (i.e., a NR configured grant).

In some embodiments, the processor 405 retriggers the SR for SCell BFRif a BFR procedure 130 is not successfully completed upon expiry of aSCell BFR timer. In some embodiments, transmitting SR on the PUCCHresources of the SR configuration includes transmitting a BFR SR usingSR configuration or PUCCH resources on a SpCell 123, if SR resources areconfigured on the SpCell 123, the SpCell 123 being one of a primary celland a primary secondary cell and performing a RACH procedure on theSpCell 123 if SR resources are not configured on the SpCell 123.

In various embodiments, the processor 405 may detect beam failure forthe SCell and initiating a Beam Failure Recovery (“BFR”) procedure. Incertain embodiments, the processor 405 ignores any received UL grantallocating resources on the SCell until successful completion of theBFR. In certain embodiments, the processor 405 controls the transceiver425 to transmit a BFR MAC CE for the SCell 125 according to an availabledynamic UL grant without transmitting a BFR scheduling request. Incertain embodiments, the processor 405 uses any valid SR PUCCH resourcesconfigured for the apparatus in response to determining that there is novalid PUCCH resource configured for SCell BFR SR. In certainembodiments, the apparatus 400 is configured by the network with a SRconfiguration to use for sending a SCell BFR SR.

In some embodiments, the processor 405 determines that the BFR procedure130 is successfully completed upon reception of a dynamic uplink grantscheduling a new transmission for the HARQ process for the SCell 125. Incertain embodiments, the processor 405 retriggers a SCell BFR SR uponexpiry of a SCell BFR timer. In one embodiment, the processor 405controls the transceiver 425 to transmit a BFR scheduling request (“SR”)using SR configuration or PUCCH resources on a Special Cell (“SpCell”)123 if SR resources are configured on the SpCell 123. In anotherembodiment, the processor 405 performs a random access (“RACH”)procedure on the SpCell 123 if SR resources are not configured on theSpCell 123.

The memory 410, in one embodiment, is a computer readable storagemedium. In some embodiments, the memory 410 includes volatile computerstorage media. For example, the memory 410 may include a RAM, includingdynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/or staticRAM (“SRAM”). In some embodiments, the memory 410 includes non-volatilecomputer storage media. For example, the memory 410 may include a harddisk drive, a flash memory, or any other suitable non-volatile computerstorage device. In some embodiments, the memory 410 includes bothvolatile and non-volatile computer storage media.

In some embodiments, the memory 410 stores data related to SCell BeamFailure recovery. For example, the memory 410 may store BFR resourceconfigurations, SR configurations, and the like. In certain embodiments,the memory 410 also stores program code and related data, such as anoperating system or other controller algorithms operating on theapparatus 400.

The input device 415, in one embodiment, may include any known computerinput device including a touch panel, a button, a keyboard, a stylus, amicrophone, or the like. In some embodiments, the input device 415 maybe integrated with the output device 420, for example, as a touchscreenor similar touch-sensitive display. In some embodiments, the inputdevice 415 includes a touchscreen such that text may be input using avirtual keyboard displayed on the touchscreen and/or by handwriting onthe touchscreen. In some embodiments, the input device 415 includes twoor more different devices, such as a keyboard and a touch panel.

The output device 420, in one embodiment, is designed to output visual,audible, and/or haptic signals. In some embodiments, the output device420 includes an electronically controllable display or display devicecapable of outputting visual data to a user. For example, the outputdevice 420 may include, but is not limited to, an LCD display, an LEDdisplay, an OLED display, a projector, or similar display device capableof outputting images, text, or the like to a user. As another,non-limiting, example, the output device 420 may include a wearabledisplay separate from, but communicatively coupled to, the rest of theuser equipment apparatus 400, such as a smart watch, smart glasses, aheads-up display, or the like. Further, the output device 420 may be acomponent of a smart phone, a personal digital assistant, a television,a table computer, a notebook (laptop) computer, a personal computer, avehicle dashboard, or the like.

In certain embodiments, the output device 420 includes one or morespeakers for producing sound. For example, the output device 420 mayproduce an audible alert or notification (e.g., a beep or chime). Insome embodiments, the output device 420 includes one or more hapticdevices for producing vibrations, motion, or other haptic feedback. Insome embodiments, all or to portions of the output device 420 may beintegrated with the input device 415. For example, the input device 415and output device 420 may form a touchscreen or similar touch-sensitivedisplay. In other embodiments, the output device 420 may be located nearthe input device 415.

The transceiver 425 includes at least transmitter 430 and at least onereceiver 435. One or more transmitters 430 may be used to provide ULcommunication signals to a base unit 121, such as the UL transmissionsdescribed herein. Similarly, one or more receivers 435 may be used toreceive DL communication signals from the base unit 121, as describedherein. Although only one transmitter 430 and one receiver 435 areillustrated, the user equipment apparatus 400 may have any suitablenumber of transmitters 430 and receivers 435. Further, thetransmitter(s) 430 and the receiver(s) 435 may be any suitable type oftransmitters and receivers. In one embodiment, the transceiver 425includes a first transmitter/receiver pair used to communicate with amobile communication network over licensed radio spectrum and a secondtransmitter/receiver pair used to communicate with a mobilecommunication network over unlicensed radio spectrum.

In certain embodiments, the first transmitter/receiver pair used tocommunicate with a mobile communication network over licensed radiospectrum and the second transmitter/receiver pair used to communicatewith a mobile communication network over unlicensed radio spectrum maybe combined into a single transceiver unit, for example a single chipperforming functions for use with both licensed and unlicensed radiospectrum. In some embodiments, the first transmitter/receiver pair andthe second transmitter/receiver pair may share one or more hardwarecomponents. For example, certain transceivers 425, transmitters 430, andreceivers 435 may be implemented as physically separate components thataccess a shared hardware resource and/or software resource, such as forexample, the network interface 440.

In various embodiments, one or more transmitters 430 and/or one or morereceivers 435 may be implemented and/or integrated into a singlehardware component, such as a multi-transceiver chip, asystem-on-a-chip, an ASIC, or other type of hardware component. Incertain embodiments, one or more transmitters 430 and/or one or morereceivers 435 may be implemented and/or integrated into a multi-chipmodule. In some embodiments, other components such as the networkinterface 440 or other hardware components/circuits may be integratedwith any number of transmitters 430 and/or receivers 435 into a singlechip. In such embodiment, the transmitters 430 and receivers 435 may belogically configured as a transceiver 425 that uses one more commoncontrol signals or as modular transmitters 430 and receivers 435implemented in the same hardware chip or in a multi-chip module.

FIG. 5 depicts one embodiment of a network equipment apparatus 500 thatmay be used for SCell Beam Failure recovery, according to embodiments ofthe disclosure. In some embodiments, the network apparatus 500 may beone embodiment of a RAN node and its supporting hardware, such as thebase unit 121, RAN node 211 and/or gNB, described above. Furthermore,network equipment apparatus 500 may include a processor 505, a memory510, an input device 515, an output device 520, and a transceiver 525.In certain embodiments, the network equipment apparatus 500 does notinclude any input device 515 and/or output device 520.

As depicted, the transceiver 525 includes at least one transmitter 530and at least one receiver 535. Here, the transceiver 525 communicateswith one or more remote units 105. Additionally, the transceiver 525 maysupport at least one network interface 540 and/or application interface545. The application interface(s) 545 may support one or more APIs. Thenetwork interface(s) 540 may support 3GPP reference points, such as Uu,N1, N2 and N3. Other network interfaces 540 may be supported, asunderstood by one of ordinary skill in the art.

The processor 505, in one embodiment, may include any known controllercapable of executing computer-readable instructions and/or capable ofperforming logical operations. For example, the processor 505 may be amicrocontroller, a microprocessor, a central processing unit (“CPU”), agraphics processing unit (“GPU”), an auxiliary processing unit, a fieldprogrammable gate array (“FPGA”), or similar programmable controller. Insome embodiments, the processor 505 executes instructions stored in thememory 510 to perform the methods and routines described herein. Theprocessor 505 is communicatively coupled to the memory 510, the inputdevice 515, the output device 520, and the transceiver 525.

In various embodiments, the processor 505 controls the network equipmentapparatus 500 to implement the above described RAN node behaviors. Forexample, the processor 505 may support one or more serving cells thatserve a UE, including a PCell and/or SCell. In various embodiments, thetransceiver 525 may receive a BFRQ, as described herein. Moreover, theprocessor 505 may allocate UL-SCH resources to a UE, as describedherein.

The memory 510, in one embodiment, is a computer readable storagemedium. In some embodiments, the memory 510 includes volatile computerstorage media. For example, the memory 510 may include a RAM, includingdynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/or staticRAM (“SRAM”). In some embodiments, the memory 510 includes non-volatilecomputer storage media. For example, the memory 510 may include a harddisk drive, a flash memory, or any other suitable non-volatile computerstorage device. In some embodiments, the memory 510 includes bothvolatile and non-volatile computer storage media. In some embodiments,the memory 510 stores data relating to SCell Beam Failure recovery, forexample storing UE identities, BFR resource configurations, SRconfigurations, resource grants, and the like. In certain embodiments,the memory 510 also stores program code and related data, such as anoperating system (“OS”) or other controller algorithms operating on thenetwork equipment apparatus 500 and one or more software applications.

The input device 515, in one embodiment, may include any known computerinput device including a touch panel, a button, a keyboard, a stylus, amicrophone, or the like. In some embodiments, the input device 515 maybe integrated with the output device 520, for example, as a touchscreenor similar touch-sensitive display. In some embodiments, the inputdevice 515 includes a touchscreen such that text may be input using avirtual keyboard displayed on the touchscreen and/or by handwriting onthe touchscreen. In some embodiments, the input device 515 includes twoor more different devices, such as a keyboard and a touch panel.

The output device 520, in one embodiment, may include any knownelectronically controllable display or display device. The output device520 may be designed to output visual, audible, and/or haptic signals. Insome embodiments, the output device 520 includes an electronic displaycapable of outputting visual data to a user. Further, the output device520 may be a component of a smart phone, a personal digital assistant, atelevision, a table computer, a notebook (laptop) computer, a personalcomputer, a vehicle dashboard, or the like.

In certain embodiments, the output device 520 includes one or morespeakers for producing sound. For example, the output device 520 mayproduce an audible alert or notification (e.g., a beep or chime). Insome embodiments, the output device 520 includes one or more hapticdevices for producing vibrations, motion, or other haptic feedback. Insome embodiments, all or portions of the output device 520 may beintegrated with the input device 515. For example, the input device 515and output device 520 may form a touchscreen or similar touch-sensitivedisplay. In other embodiments, all or portions of the output device 520may be located near the input device 515.

As discussed above, the transceiver 525 may communicate with one or moreremote units and/or with one or more network functions that provideaccess to one or more PLMNs. The transceiver 525 operates under thecontrol of the processor 505 to transmit messages, data, and othersignals and also to receive messages, data, and other signals. Forexample, the processor 505 may selectively activate the transceiver (orportions thereof) at particular times in order to send and receivemessages.

The transceiver 525 may include one or more transmitters 530 and one ormore receivers 535. In certain embodiments, the one or more transmitters530 and/or the one or more receivers 535 may share transceiver hardwareand/or circuitry. For example, the one or more transmitters 530 and/orthe one or more receivers 535 may share antenna(s), antenna tuner(s),amplifier(s), filter(s), oscillator(s), mixer(s),modulator/demodulator(s), power supply, and the like. In one embodiment,the transceiver 525 implements multiple logical transceivers usingdifferent communication protocols or protocol stacks, while using commonphysical hardware.

FIG. 6 depicts one embodiment of a method 600 for SCell Beam Failurerecovery, according to embodiments of the disclosure. In variousembodiments, the method 600 is performed by a UE, such as the remoteunit 105, the UE 205, and/or the user equipment apparatus 400, describedabove. In some embodiments, the method 600 is performed by a processor,such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliaryprocessing unit, a FPGA, or the like.

The method 600 begins and receives 605 a SR configuration from awireless communication network. Here, the SR configuration comprising aset of PUCCH resources, where the SR configuration corresponds to one ormore logical channels. The method 600 includes detecting 610 that a beamfailure recovery procedure has been triggered for a SCell in thewireless communication network. The method 600 includes triggering 615 aSR for SCell beam failure recovery in response to determining that thereare no UL-SCH resources available for a new transmission for thetransmission of a beam failure MAC CE. The method 600 includestransmitting 620 SR on the PUCCH resources of the SR configuration inresponse to triggering the SR for SCell beam failure recovery. Themethod 600 ends.

Disclosed herein is a first apparatus for SCell Beam Failure recovery,according to embodiments of the disclosure. The first apparatus may beimplemented by a UE, such as the remote unit 105, the UE 205 and/or theuser equipment apparatus 400, described above. The first apparatusincludes a transceiver that communicates with a SCell in a wirelesscommunication network. The first apparatus includes a processor thatreceives a SR configuration from a wireless communication network, theSR configuration comprising a set of PUCCH resources, where the SRconfiguration corresponds to one or more logical channels. The processordetects that beam failure procedure has been triggered for the SCell.The processor triggers a scheduling request for SCell beam failurerecovery in response to determining that there are no UL-SCH resourcesavailable for a new transmission for the transmission of a beam failureMAC CE. The processor transmits SR on the PUCCH resources of the SRconfiguration in response to triggering the scheduling request for SCellbeam failure recovery.

In some embodiments, the processor receives a configuration from thewireless communication network indicating that SCell beam failurerecovery is mapped to the SR configuration. In some embodiments, theprocessor further determines that an UL resource allocation is availablefor a new transmission in response to the transmission of the schedulingrequest. Here, the UL resource allocation is associated with a HARQprocess and controls the transceiver to transmit a beam failure MAC CEon the allocated uplink resource.

In some embodiments, the processor receives (i.e., via the transceiver)a dynamic UL grant that schedules a new transmission for the HARQprocess on which the beam failure MAC CE was transmitted. The processordetermines that a beam failure recovery procedure is successfullycompleted in response to reception of the dynamic UL grant. In suchembodiments, the dynamic UL grant includes DCI addressed to a C-RNTI ofthe UE, where the dynamic UL grant has an NDI that is toggled ascompared to a reference NDI for the HARQ process.

In some embodiments, receiving the SR configuration includes receiving abeam failure recovery SR configuration including a PUCCH resource for aSCell BFRQ and including parameters related to a SCell beam failurerecovery SR procedure. In one embodiment, the beam failure recovery SRconfiguration is configured on one of: a primary cell and a primarysecondary cell (i.e., on a SpCell 123). In another embodiment, the beamfailure recovery SR configuration is configured on a different SCell(i.e., an SCell configured with the RRC parameter ‘PUCCH-Config’).

In some embodiments, transmitting SR on the PUCCH resources of the SRconfiguration includes sending a beam failure recovery SR using anyvalid SR PUCCH resources configured for the UE in response todetermining that there is no valid PUCCH resource configured for SCellbeam failure recovery SR. In some embodiments, the processor ignoresreceived UL grants allocating resources on the SCell until successfulcompletion of a beam failure recovery procedure.

In some embodiments, the processor transmits the beam failure MAC CE forthe SCell according to an available dynamic uplink grant in response todetermining that there are UL-SCH resources available for a newtransmission. In certain embodiments, the processor prevents the beamfailure MAC CE from being sent on a semi-persistently scheduled uplinkresource (i.e., a NR configured grant).

In some embodiments, the processor retriggers the SR for SCell beamfailure recovery if a beam failure recovery procedure is notsuccessfully completed upon expiry of a SCell beam failure recoverytimer. In some embodiments, transmitting SR on the PUCCH resources ofthe SR configuration includes transmitting a beam failure recoveryscheduling request using SR configuration or PUCCH resources on a SpCell123, if SR resources are configured on the SpCell 123, the SpCell 123being one of a primary cell and a primary secondary cell and performinga RACH procedure on the SpCell 123 if SR resources are not configured onthe SpCell 123.

Disclosed herein is a first method for SCell Beam Failure recovery,according to embodiments of the disclosure. The first method may beperformed by a UE, such as the remote unit 105, the UE 205 and/or theuser equipment apparatus 400, described above. The first method includesreceiving a SR configuration from a wireless communication network, theSR configuration comprising a set of PUCCH resources, wherein the SRconfiguration corresponds to one or more logical channels. The firstmethod includes detecting that a BFR procedure 130 has been triggeredfor a SCell 125 in the wireless communication network. The first methodincludes triggering a scheduling request for SCell BFR in response todetermining that there are no UL-SCH resources available for a newtransmission for the transmission of a beam failure MAC CE andtransmitting SR on the PUCCH resources of the SR configuration inresponse to triggering the scheduling request for SCell beam failurerecovery.

In some embodiments, the first method includes receiving a configurationfrom the wireless communication network indicating that SCell beamfailure recovery is mapped to the SR configuration. In some embodiments,the first method includes determining that an UL resource allocation isavailable for a new transmission in response to the transmission of thescheduling request. Here, the UL resource allocation is associated witha HARQ process and transmitting a beam failure MAC CE on the allocateduplink resource.

In certain embodiments, the first method further includes receiving adynamic UL grant that schedules a new transmission for the HARQ processon which the beam failure MAC CE was transmitted and determining that abeam failure recovery procedure is successfully completed in response toreception of the dynamic UL grant. In such embodiments, the dynamic ULgrant may include DCI addressed to a C-RNTI of the UE, wherein thedynamic UL grant has an NDI that is toggled (i.e., as compared to areference NDI for the HARQ process).

In some embodiments, receiving the SR configuration comprises receivinga BFR SR configuration including a PUCCH resource for a SCell BFRQ andincluding parameters related to a SCell BFR SR procedure. In oneembodiment, the BFR SR configuration is configured on one of a primarycell and a primary secondary cell (i.e., on a SpCell 123). In anotherembodiment, the BFR SR configuration is configured on a different SCell(i.e., an SCell configured with the RRC parameter ‘PUCCH-Config’).

In some embodiments, transmitting SR on the PUCCH resources of the SRconfiguration comprises sending a beam failure recovery SR using anyvalid SR PUCCH resources configured for the UE in response todetermining that there is no valid PUCCH resource configured for SCellbeam failure recovery SR. In some embodiments, the first method includesignoring received UL grants allocating resources on the SCell untilsuccessful completion of a beam failure recovery procedure.

In some embodiments, the first method includes transmitting the beamfailure MAC CE for the SCell according to an available dynamic uplinkgrant in response to determining that there are UL-SCH resourcesavailable for a new transmission. In certain embodiments, the firstmethod also includes preventing the beam failure MAC CE from being senton a semi-persistently scheduled uplink resource (i.e., configuredgrant). In some embodiments, the first method includes retriggering theSR for SCell beam failure recovery if a beam failure recovery procedureis not successfully completed upon expiry of a SCell beam failurerecovery timer.

In some embodiments, transmitting SR on the PUCCH resources of the SRconfiguration includes transmitting a beam failure recovery schedulingrequest using SR configuration or PUCCH resources on a SpCell 123, if SRresources are configured on the SpCell 123, the SpCell 123 being one ofa primary cell and a primary secondary cell and performing a RACHprocedure on the SpCell 123, if SR resources are not configured on theSpCell 123.

Embodiments may be practiced in other specific forms. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

1. A method of a user equipment device (“UE”) comprising: receiving ascheduling request (“SR”) configuration from a wireless communicationnetwork, the SR configuration comprising a set of Physical UplinkControl Channel (“PUCCH”) resources, wherein the SR configurationcorresponds to one or more logical channels; detecting that a beamfailure recovery procedure has been triggered for a secondary cell(“SCell”) in the wireless communication network; triggering a Schedulingrequest for SCell beam failure recovery in response to determining thatthere are no Uplink Shared Channel (“UL-SCH”) resources available for anew transmission for the transmission of a beam failure Medium AccessControl (“MAC”) control element; and transmitting SR on the PUCCHresources of the SR configuration in response to triggering thescheduling request for SCell beam failure recovery.
 2. The method ofclaim 1, the method further comprising: receiving a configuration fromthe wireless communication network indicating that SCell beam failurerecovery is mapped to the SR configuration.
 3. The method of claim 1,the method further comprising: determining that an uplink (“UL”)resource allocation is available for a new transmission in response tothe transmission of the scheduling request, wherein the UL resourceallocation is associated with a Hybrid Automatic Repeat Request (“HARQ”)process; and transmitting a beam failure MAC CE on the allocated uplinkresource.
 4. The method of claim 3, the method further comprising:receiving a dynamic UL grant that schedules a new transmission for theHARQ process on which the beam failure MAC CE was transmitted; anddetermining that a beam failure recovery procedure is successfullycompleted in response to reception of the dynamic UL grant.
 5. Themethod of claim 4, wherein the dynamic UL grant comprises downlinkcontrol information addressed to a cell-specific radio network temporaryidentifier of the remote unit, wherein the dynamic UL grant has a newdata indicator (“NDI”) that is toggled as compared to a reference NDIfor the HARQ process.
 6. The method of claim 1, wherein receiving the SRconfiguration comprises receiving a beam failure recovery SRconfiguration including a PUCCH resource for a SCell beam failurerecovery request (“BFRQ”) and including parameters related to a SCellbeam failure recovery SR procedure.
 7. The method of claim 6, whereinthe beam failure recovery SR configuration is configured on one of aprimary cell and a primary secondary cell.
 8. The method of claim 6,wherein the beam failure recovery SR configuration is configured on adifferent SCell.
 9. The method of claim 1, wherein transmitting SR onthe PUCCH resources of the SR configuration comprises sending a beamfailure recovery SR using any valid SR PUCCH resources configured forthe remote unit in response to determining that there is no valid PUCCHresource configured for SCell beam failure recovery SR.
 10. The methodof claim 1, the method further comprising: ignoring received uplink(“UL”) grants allocating resources on the SCell until successfulcompletion of a beam failure recovery procedure.
 11. The method of claim1, the method further comprising: transmitting the beam failure MACcontrol element for the SCell according to an available dynamic uplinkgrant in response to determining that there are UL-SCH resourcesavailable for a new transmission.
 12. The method of claim 11, the methodfurther comprising: preventing the beam failure MAC control element frombeing sent on a semi-persistently scheduled uplink resource.
 13. Themethod of claim 1, the method further comprising: retriggering the SRfor SCell beam failure recovery if a beam failure recovery procedure isnot successfully completed upon expiry of a SCell beam failure recoverytimer.
 14. The method of claim 1, wherein transmitting SR on the PUCCHresources of the SR configuration comprises: transmitting a beam failurerecovery scheduling request using SR configuration or PUCCH resources ona Special Cell (“SpCell”) if SR resources are configured on the SpCell,the SpCell being one of a primary cell and a primary secondary cell; andperforming a random access (“RACH”) procedure on the SpCell if SRresources are not configured on the SpCell.
 15. An apparatus comprising:a transceiver that communicates with a secondary cell (“SCell”) in awireless communication network; and a processor that: receives ascheduling request (“SR”) configuration from a wireless communicationnetwork, the SR configuration comprising a set of Physical UplinkControl Channel (“PUCCH”) resources, wherein the SR configurationcorresponds to one or more logical channels; detects that beam failureprocedure has been triggered for the SCell; triggers a schedulingrequest for SCell beam failure recovery in response to determining thatthere are no Uplink Shared Channel (“UL-SCH”) resources available for anew transmission for the transmission of a beam failure Medium AccessControl (“MAC”) control element; and transmits SR on the PUCCH resourcesof the SR configuration in response to triggering the scheduling requestfor SCell beam failure recovery.
 16. The apparatus of claim 15, whereinthe processor receives a configuration from the wireless communicationnetwork indicating that SCell beam failure recovery is mapped to the SRconfiguration.
 17. The apparatus of claim 15, wherein the processorfurther: determines that an uplink (“UL”) resource allocation isavailable for a new transmission in response to the transmission of thescheduling request, wherein the UL resource allocation is associatedwith a Hybrid Automatic Repeat Request (“HARQ”) process; and transmits abeam failure MAC CE on the allocated uplink resource.
 18. The apparatusof claim 17, wherein the processor further: receives a dynamic UL grantthat schedules a new transmission for the HARQ process on which the beamfailure MAC CE was transmitted; and determines that a beam failurerecovery procedure is successfully completed in response to reception ofthe dynamic UL grant.
 19. The apparatus of claim 18, wherein the dynamicUL grant comprises downlink control information addressed to acell-specific radio network temporary identifier of the remote unit,wherein the dynamic UL grant has a new data indicator (“NDI”) that istoggled as compared to a reference NDI for the HARQ process.
 20. Theapparatus of claim 15, wherein receiving the SR configuration comprises:receiving a beam failure recovery SR configuration including a PUCCHresource for a SCell beam failure recovery request (“BFRQ”) andincluding parameters related to a SCell beam failure recovery SRprocedure.